No C for me thank you

Limbic Region on 2008-08-08T23:01:30

Recently, I ported some C code to Perl. The reason this was done was purely bureaucratic. I am a mediocre C programmer at best so perhaps my lack of expertise made this process more painful than it would have been otherwise. In any event, I am happy to continue blissfully ignoring C (sorry Parrot).

I found that the LOC was reduced by about 10:1. Some of the issues I ran into were obvious - working with sockets at a low level was challenging because I am used to using abstraction modules like IO::Socket::INET and IO::Select. Some of the other issues might not have been so obvious.

You don't translate C line by line. You read a block of code, figure out what it is trying to accomplish (ignoring how it is accomplishing it) and then write the line or 2 of equivalent Perl. My problem is that I don't have enough experience to ignore the "how". I mentally keep track of each thing happening in turn until I reach the "a ha" line that makes it clear why all the previous steps were necessary.

That sucks.


C's Chinese to me.

mr_bean on 2008-08-09T00:22:36

Sounds like the way I read Chinese.
More bottom-up than top-down.

and ruby for thee?

slanning on 2008-08-11T08:15:36

One of my personal theories for why Ruby, etc., are more successful recently is that they abstract away more than Perl does, or at least they abstract away more important things. It's not so much the languages themselves but the mindset of the communities. It's one reason why I don't think Perl 6 is going to "turn things around" for Perl. [skip list of disclaimers for warding off flames :} ] We're going to end up rewriting a lot of existing functionality in Perl 6, but I don't think that will lead to more abstraction. As with a strategy game like Civilization, I think we need to concentrate on building up our production, which in this stupid analogy I'm making means making better abstractions, like on the level of CPAN modules. If only I knew which abstractions need making... :)

Re:and ruby for thee?

chromatic on 2008-09-29T21:08:33

One of my personal theories for why Ruby, etc., are more successful recently is that they abstract away more than Perl does, or at least they abstract away more important things.

Declarative classes (seriously, @ISA in 2008?) and blocks (such as they are) really do help Ruby abstractions.

We're going to end up rewriting a lot of existing functionality in Perl 6, but I don't think that will lead to more abstraction.

Multidispatch, to choose one random feature, really improves abstraction and conciseness -- and the declarative syntax pushes the cost of the feature down. Roles may be a better example.

Re:and ruby for thee?

Aristotle on 2008-09-30T06:56:56

Considering the breadth of things that Perl 6 adds, at levels of abstraction that no other current mainstream-aimed language even attempts, I find it hard not to reject that statement as absurd. Junctions, laziness, multi-dispatch, roles, grammars… there are so many things.

Can you name anything that Perl 6 is missing? Or name any language that already has a significant portion of the things Perl 6 is meant to provide?

Re:and ruby for thee?

slanning on 2008-10-01T12:47:20

Aristotle. When you use jargon like that it's not very convincing to me. (I see a crow outside searching for food!) It doesn't mean much to me or connect to my experience, so I just kind of "reject that statement as absurd", as you put it. (I heard a plane just take off from the airport!) Junctions, those must....join things or something I guess, like the internet tubes? And grammars, I know you ain't supposed to say "ain't" and things like that. (The French class across the hall just let out, and they were chatting really loud!) But what do those things have to do with my CRAP database interfaces?

Re:and ruby for thee?

slanning on 2008-10-01T12:48:26

Durr, I mean CRUD. In a reply to myself to give the impression that I was in such a hurry and not concentrating when I originally replied.

Re:and ruby for thee?

Aristotle on 2008-10-01T13:37:01

I was simply trying to avoid assuming that you passed judgement about Perl 6 without knowing the first thing about it. But you are now stating that that was indeed the case, and further that jargon does not mean much to you. So you’ll excuse me for leaving it to Perl 6 itself to convince you whenever it rolls around; I haven’t the stamina to type in this textbox an introduction from scratch into each of these features that will properly convey to you how it will help you in the trenches. That would equate to a small book, or at least one chapter each per feature.

Ruby and Python along with Perl 5 and Javascript are just status quo: all of them very similar languages in terms of expressive devices. Perl 6 is a generation beyond all of them.

Re:and ruby for thee?

slanning on 2008-10-01T14:38:08

So you’ll excuse me for leaving it to Perl 6 itself to convince you whenever it rolls around

I definitely will, Aristotle.

properly convey to you how it will help you in the trenches. That would equate to a small book

That's even assuming I bother with it at all in the first place. Life is short, and I'm not sure yet if it's worth my time, eh?

Ruby and Python along with Perl 5 and Javascript are just status quo: all of them very similar languages in terms of expressive devices. Perl 6 is a generation beyond all of them.

If you say so! Even Smalltalk? :)

Re:and ruby for thee?

Aristotle on 2008-10-01T15:18:54

Smalltalk as a language is not in the same cluster as these popular dynamic languages. But it’s also more than just a language. It includes a platform and even a different model of the act of programming.

Perl 6 together with Parrot and some form of in-process development environment that nobody has given any thought to so far might provide something roughly comparable. I think there would still be significant differences, though. Much would depend on this fictional development environment, so little can be stated with certainty.

It’s just hard to make any direct comparisons of Smalltalk with Perl 6. There are too many differences.